어제 세웠던 Try 돌아보기

현재 구성되어있는 알림톡 목록의 발송일자, 발송규칙을 정리한다. 구글 스프레드시트에 발송 규칙에 대해 정리했다. 각각의 알림톡의 발송 시간, 대상, DB에 저장되는 Enum의 형태를 포함했다.
각각의 이상치 탐지 기준을 정의한다. 이상치 탐지 기준은 발송 지연, 발송 누락, 발송모수 이상 3가지를 기준으로 잡았다.
1시간마다 발송 현황을 올리는 채널은 유지하면서 별도의 batch로 이상치 감지 패턴을 추가한다. 발송 현황을 올리는 채널은 유지했다. 별도의 batch를 구현하는 과정에서 스케줄링의 중앙화에 대한 고민을 계속했다. 현재 사내에서 databricks를 사용중인데 모니터링 테이블을 CDC한 뒤 job을 하나 만들어서 알림톡 감지로직을 돌리는게 레거시 프로젝트에 불필요한 배치 코드 추가하지 않고도 구성이 가능하다고 생각했다.

현재 사정상 CDC를 수행할때 최대 5분의 텀이 있는데 한데 모니터링용이라서 크게 상관없다고 생각한다. 알림톡 발송 내역을 적재하고있는 테이블을 CDC 요청했다.

TMI: 기존에 알림 발송 형태가 레거시 시스템에서 발송하던 형태와, 신규 장부팀에서 발송하는 알림톡의 형태가 다르게 저장되고 있었다. 12월 17일에 위 내용을 해결하고자 두개의 알림톡을 표준화해서 저장했다. 며칠간 데이터가 쌓이는걸 지켜보다가 오늘 Dual write가 잘 수행되는것을 확인했다. 내일은 기존 DB에 쌓여있던 데이터를 신규 DB로 마이그레이션 해도 될것 같다.

Keep

잘 한점. 혹은 유지할만한점

오늘 수행할 try에 대해 노트에 적어두었다.
회사에 요청한 화이트보드를 오늘 받아서 하고자 하는 일에 대해 작성해두었다
- 혼자 생각하는 시간이 생기는데 동료들이 지나다니면서 내 고민에 의견을 편하게 제시할 수 있도록 화이트보드를 갖다놓고 기획을 적어두었다.
- 야근하면서 적어둔거라 내일부터 의견을 받아볼 수 있을 것 같다.
- 관련해서 관측이 더 필요한 정책이나 운영에 필요한 요소가 있다면 추가로 의견을 수렴해볼 예정이다.
더 넓은 시야로 바라보기
- 단순히 눈앞의 환경에 매몰되지 않고 시스템적으로 다른 대안은 없을지 살펴봤던 점이 좋았다.
- 기존에는 눈앞의 kotlin, spring 프로젝트에 초점을 맞추고 있었는데 생각해보니 DB만 있으면 이상치 감지 로직은 어디에 있어도 상관없을거같다는 생각이 들었다.
- databricks에서
안정적인 마이그레이션
- dual write를 수행하고 저장되는 알림톡 종류, 갯수를 모두 검증할 수 있었다.
- 안정적으로 이관하는 습관을 들이면 좋을것 같다.

Problem

문제점. 개선할점

일단 CDC를 했을 때 5분 지연이 괜찮다고 판단했었지만, 중요한 알림 발송 시 이 5분이 골든타임을 놓치는게 크리티컬하게 작용하지는 않을지 검토할 필요가 있어보인다.
내일 수행할 테이블 마이그레이션 규모가 우려된다. 알림 발송 내역을 전부 저장하다 보니 5일 만에 천만 건이 쌓였다. 이 추세라면 월 6,000만 건 이상이 예상되는데, 기존 정책(3개월 보관)에 맞춰 일별 집계 데이터와 싱크를 맞추는 작업이 병행되어야겠다.

Try

새롭게 시도할점

알림톡 발송내역 관련 테이블 정리. 기존 레거시 데이터를 신규 표준 테이블로 마이그레이션한다.
화이트보드 피드백 수집하기. 같은 팀 동료들과 이야기를 나눠보고 더 좋은 대안책 혹은 더 필요한 내용이 있을지 검토해본다.
CDC 지연에 영향을 받는 알림톡이 있는지 검토한다. (만약 있다면 Application 레벨 혹은 라이브러리 레벨에서의 Alert도 생각해보자)

느낀점 및 자유로운 생각

AI가 정리를 다 해주는 세상이지만, 화이트보드로 직접 도식화하니 오히려 집중이 더 잘 됐다. 요새 AI를 활용하다 보면 모든 작업을 비동기로 처리하고 싶어지는 욕심이 생기곤 하는데, 정책이나 데이터를 정리하는 시점에는 이런 아날로그적인 작업이 몰입도와 정리 효율 면에서 훨씬 효과적인 것 같다.

오늘 점심 무렵 나누었던 **Resume Driven Development(RDD)**에 대한 이야기가 내내 머릿속을 떠나지 않는다.

자신이 가고 싶은 회사의 기술 스택을 타당한 근거 없이 무리하게 도입하고는, 정작 본인은 더 좋은 기업으로 이직해 버리는 사례들을 종종 본다. 그들이 남기고 간 기술적 허영심의 산물을 감당해야 하는 남겨진 이들의 고통을 생각하면, 과연 기업들의 레퍼런스 체크가 제 역할을 하고 있는 건지 의구심마저 든다.

물론 개인의 커리어 성취도 중요하지만, 적어도 나는 동료들에게 그런 고통을 남기는 엔지니어가 되고 싶지는 않다. 돌이켜보면 우테코 수료 이후, 하나의 목표를 향해 동료들과 함께 치열하게 고민하고 몰입했던 경험이 무척 그리워진다.

엔지니어의 본질은 결국 조직이 마주한 병목을 찾아 근본적인 원인을 해결하고, 모두가 본질적인 업무에만 집중할 수 있는 단단한 환경을 만드는 데 있는 게 아닐까? 당연하다고 믿어온 이 가치들에 대해 유난히 고민이 깊어지는 밤이다.

요즘 내가 속한 조직에 어떤 이야기를 해야 내가 바라는 '몰입하는 문화'를 만들 수 있을까 고민이 많다. 때로는 퍼블릭 채널에 선언을 하거나 CTO에게 직접 제안하는 상상도 해보지만, 결국 개인이 이끄는 변화에는 한계가 명확하다. 결국 중요한 것은 투명한 공유와 작은 성공 경험을 쌓아가는 데 있다고 믿는다.

오늘 꺼내든 화이트보드와, 그간 꾸준히 지속해온 사내 AI 활용 사례 공유가 그 시발점이다. AI 앰버서더라는 명분상의 직함보다 중요한 것은, 동료들이 실제로 AI를 업무에 녹여내 효율을 얻는 과정을 직접 목격하고 체감하게 하는 것이라 생각한다. 투명한 공유와 몰입하는 문화를 향한 나의 이런 분투가 조직에 어느 정도까지 긍정적인 영향을 미칠 수 있을지, 계속해서 다양한 시도를 이어가 보려 한다.

러너스하이 하다가 새벽 감성에 기분이 High 해지는것 같다 😅